In the context of current communication systems, one significant problem to be solved lies in the increasing size of the throughputs of information that these systems have to support. Specifically, communication networks are made available to subscriber users, who generally use them as they wish and completely asynchronously, such that, when the throughput required on one branch of a communication network is too high, the network is saturated resulting in a slowdown of the data exchanges, possibly accompanied by losses of information packets.
This phenomenon is particularly sensitive in the context of data exchanges via the Internet on account of the increase in the number of connections to the network and the increasingly large size of the data exchanged between the users subscribed to the network and the data exchanged between the users (‘clients’) and remote information storage zones or databases (‘servers’).
One solution that is contemplated for dealing with this increase consists in simultaneously using two or more separate communication channels that the user may have available on his terminal to transmit or receive the desired information.
In the context of the Internet, such a solution involves developing the existing data exchange protocol, the TCP protocol, such that the latter is capable of simultaneously managing data flows (reference is made to ‘subflows’) flowing through various channels and intended to be linked together so as to form a single data flow at the user end, which data flow is intended to supply a given application that is implemented by this user (data storage in a remote storage centre or reading video files that are transmitted via a remote broadcasting platform, for example).
This development of the TCP protocol has given rise to the MP-TCP protocol, which is in the process of being standardized. This improved protocol in particular has the advantage of impacting only the transport layer of the communication network under consideration.
‘MP-TCP’ constitutes an extension of the ‘TCP’ standard transport protocol that makes it possible to add what are termed ‘multipath’ (‘MP’) capabilities to this protocol.
One typical case in which the ‘MP-TCP’ protocol is implemented, as is able to be contemplated at the present time, is that of smartphones. Smartphones are typically devices that are provided with 2 network access interfaces: an interface with mobile telephony networks, with the 3G/4G standards for example, and a Wi-Fi™ interface with an Internet terminal (‘set top box’ or simply ‘box’).
FIG. 1 illustrates the principle of use of two separate Internet access mechanisms using the MP-TCP protocol, taking, as a typical exemplary application, the application to smartphones.
In such a hardware configuration, the ‘MP-TCP’ protocol enables utilization of the two networks (3G/4G and Wi-Fi™) to download or read data from one and the same server, as long as the latter supports this protocol, by combining the capabilities of the two networks to provide one and the same overall transport service from the point of view of the application.
In this case, the data take 2 physically different paths (in an unbroken line and in a dashed line in FIG. 1) that are predetermined depending on the IP addresses of the clients and servers.
These paths may possibly take a shared section, as illustrated in FIG. 1, between one of the routers of the network and the TCP server, this router not having any particular functionality.
It is recalled at this juncture that a protocol of MP-TCP type thus makes it possible to create and manage secondary data flows (‘subflows’) that are associated with interface/address pairs that are different, but that are also partly or completely identical.
The integration of the multipath functionality into a conventional TCP protocol naturally assumes various developments.
In particular, it assumes the integration of a dedicated software layer located below the interface layer to the application, which for its part remains unchanged. Only the software implementation (typically in the kernel of the OS or ‘operating system’) is slightly different in practice.
Functionally, this implementation is managed in the TCP client/server software stack by providing two sublayers: the MP-TCP sublayer, strictly speaking, which is aware of all of the secondary data flows (‘subflows’), and the ‘subflow’ sublayer, which is simply the local implementation of a conventional TCP connection (i.e. not ‘MP’) with the IP interface of each of the channels conveying the secondary data flows (‘subflows’).
Integrating the multipath (‘MP’) functionality also assumes specific signalling and message creation that enable an MP-TCP-compatible machine to determine whether its correspondent is MP-TCP-compatible, to be informed that a local interface of a host is available for ‘multipath’ communication, and then to create ‘subflows’ as such.
Integrating the multipath functionality into a conventional TCP protocol however remains an advantageous solution in that it makes it possible to preserve virtually all of the pre-existing hardware and software infrastructures.
The set of rules governing the implementation and utilization of MP-TCP links forms the subject of the document ‘request for comments’ RFC6824, which describes the technical aspects of the MP-TCP protocol.
The solution consisting in implementing an MP-TCP protocol to increase the data transfer throughput on a network, in particular the Internet, therefore requires having a plurality of available transmission channels through which the data packets are transited in a plurality of flows that are recombined on arrival so as to reproduce the expected data frame.
However, each channel is supposed to be able to support bidirectional exchanges (data and protocol) between transmitter and receiver, one path (‘outward’ path) being dedicated to the transfer of data from the transmitter to the receiver, while another path (‘return’ path) is dedicated to the transfer of acknowledgement information between the receiver receiving the data and the transmitter. This acknowledgement information is necessary for controlling congestion on the network path under consideration and for increasing reliability of the transfer so as to trigger retransmissions when this proves necessary.
Now, it should be noted that, with regard to transferring data via satellite for use by the general public, two separate types of link are generally available: bidirectional links that enable communications of ‘broadband’ type, and unidirectional links that enable communications of ‘broadcast’ type, the second type of link being much more widespread at the present time.
Therefore, in the context of a transmission of data via satellite in accordance with a TCP protocol, it is not always possible to increase the data transmission throughput by implementing an MP-TCP protocol, which protocol assumes that a plurality of transmission channels are available and requires, like the TCP protocol, the implementation of bidirectional data flows.
In particular, in the context of data links involving a plurality of satellite channels, implementing links following an MP-TCP protocol does not always constitute, at the present time, a solution that is able to be contemplated for increasing the throughput, due to the lack of a sufficient number of available bidirectional data links. The problem arises since the lack of a sufficient number of return paths prevents the effective multipath transport solutions, such as MP-TCP, from being able to be deployed in this context. Specifically, the receipt acknowledgements (‘ACK’ signals) that make it possible, by detecting packet losses, to determine the congestion level and congestion events in order for the data transmitter to take the necessary actions, are transported and signalled via the return path.
To solve this problem that is inherent to satellite links, asymmetric and unidirectional routing methods (such as the UDLR (‘UniDirectional Link Routing’) solution) have been envisaged, in particular implementing a unidirectional satellite link that is coupled to a terrestrial return path.
However, such a solution proves not to be completely suitable for the problem. Specifically, in so far as it is generally implemented at the routing layer (layer 3), possible congestion that may arise separately on each of the two paths is not able to be taken into account overall.
Moreover, in order to at least partially solve this problem, ‘smart router’ solutions are commercially available, these performing load sharing at the data packet transmission level by implementing various distribution algorithms. However, these devices are not able to work at the transport layer level and are therefore not able to make effective decisions that are able to be applied to ‘standard’ interfaces with the network. Worse still, in the case of applications using the MP-TCP protocol, the ‘smart router’ could make incoherent routing decisions that are incompatible with the MP-TCP protocol.
What is more, in addition to these load sharing solutions and ‘multihoming’ functions (i.e. simultaneous connection to a plurality of networks) that are implemented at the transport layer level, mention may also be made of the implementation of PEP-TCP (PEP for ‘Performance Enhancement Proxy’) functions. This type of function advantageously makes it possible to avoid, to a certain extent, possible congestion that may arise on a data link, in particular in the case of using a satellite transmission channel.
Lastly, a partial solution to this problem may also consist of a data transmission system implementing the MP-TCP protocol between PEPs at a satellite gateway (or ‘GW’) and satellite terminals.